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(57) Abstract: The present invention relates generally to a method and system for end-user controlled processing and routing of 
messages based upon parameters other than message destination address, such as Time, Location, Subscriber Identity, Equipment 
Identity and Service Control Commands, etc in a mobile radio communication system. The Service Control Commands, which are 
transferred as part of the message and handle the control and request of specific network services, are transferred to a central message 
processing point, the Message Handling Server, which can understand these commands and act upon them. A set of commands is 
presented that allow the end user to control aspects of his/her pre-payment service, messaging service, ascertain the availability of 
others, locate others and indicate that others are allowed to locate the end-user, etc. 
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METHOD AND SYSTEM RELATING TO CONTROL OF MOBILE 
RADIO MESSAGING COMMUNICATIONS 



5 Field of the Invention 

The present invention relates generally to the field of mobile radio messaging 
communications, and more particularly to a method and system for handling mobile system 
end-user service preferences and behaviour via mobile messaging in a mobile radio 
communication system. 

10 

Background of the Invention 

Mobile radio telephony has become an important part of today' s society, and many people 
are in the possession of a Mobile Station. One of the most widely used forms of 

15 communication using these Mobile Stations is messaging, which encompasses the sending 
of text, pictures, audio or other media content to and from Mobile Stations. Routing of the 
message to its destination can be via for example an e-mail server, a short message service 
centre or a multi-media messaging service centre. The type of messaging can be performed 
either by virtual circuit establishment for confirmed transfer, or via datagram for 

20 unconfirmed transfer. - - - 

Irrespective of the way message contents are transferred, it is beneficial for the end-user of 
the Mobile Station sending a message to be able to control the way that messaging and 
other services provided by the network to the user are performed. It is also beneficial for 

25 the end-user and/or the service provider to be able to route messages not only based on 
message destination address, but based on other parameters as well. These parameters 
could be used in combination or in place of message destination address, and include 
equipment and subscriber identifiers such as International Mobile Station Identifier (IMSI), 
Intemational Mobile Equipment Identifier (IMEI); commands embedded in the content of 

30 messages; time; etc. These routing analysis altematives may be svunmaiised by stating that 
routing is best performed using a combination of one or more end-user controlled 
parameters and one or more network parameters. Examples of end-user controlled 
parameters are the destination address, message originating address (if the end-user is 
subscribed to services such as multiple subscriber profile) and commands embedded in 

35 message user data, whilst examples of the network-based parameters are time, IMEI, IMSI, 
originating or terminating party location, etc. 

Routing analysis performed in this way allows the user to be able to request notification 
when an end user has attached to the network and is thus reachable for instant messaging 

40 purposes, to append his location, to request the location of the party or parties to whom the 
message was delivered, etc. A simple way of controlling message routing and handling 
using message user data is to construct the messaging system such that the message 
contains control information to indicate how analysis shall be performed, and upon what 
message or network information. A central message processing point then analyses the 

45 control information plus relevant message parameters and selects an Application that can 
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provide further handling of the message. This handling may include changing the 
destination address to modify onward routing of the message, reformatting the message, 
adding elements to the message, terminating the message and sending a response, 
interacting with other network services, etc. 

5 

For this flexible control of message-handling to be exercised in the network using 
parameters other than destination address that are embedded in the message itself or using 
network parameters such as location or time, it is sufficient to construct suitable handling 
in the central message processing point. However, for flexible control of message handling 

10 to be exercised in the network using message user data, the end-user must instruct 

("command") the network regarding the control to be exercised, and the network must be 
able to understand these instructions ("commands"). These commands and the parameters 
other than message destination address will be parsed by the short message service centre, 
multi-media messaging service centre, e-mail server, etc that has been adapted to interpret 

15 the commands - henceforth referred to by the generic name of Message Handling Centre 

For the user and for the network operator, it is beneficial if the method of defining the 
commands requires change at only the network side to introduce new commands. This is 
because the user is significantly disadvantaged if a new terminal has to be purchased to 

20 support new conmiands and the network operator is significantly disadvantaged if any 

network nodes other that the server acting as the conmiand interpreter need to be updated 
or purchased, in both cases, the penalty is in terms of cost and convenience. In addition, it 
is beneficial if the conmiands are introduced in user data, as they are then portable between 
standardised messaging specifications and require no synchronisation of protocol 

25 parameter usage and definition between these specifications, such as would be required if 
user-specific fields were to be used in GSM SMS-specific User Data Header SMSC- 
specific parameters. Such synchronisation again causes considerable disadvantage to the 
end-user, as it is difficult to achieve. 

30 In order to address these disadvantages, it is proposed to embed the commands directly into 
the transferred media content, such that only the end-user and the server acting as the 
conomand interpreter need handle the input and analysis of the conmiands. This approach 
allows the commands to be used across multiple messaging systems and terminal types, 
with the use of different media types also possible. As an example, to append the message 

35 originators' location using the GSM short message system for data transfer, the character 
combination ".A" can be used to indicate append as the first characters in the message user 
data. If the UMTS multi-media messaging service is being used then a suitable graphic or 
audio clip indicating location append can be included as user data e.g. a picture of a Mobile 
Station or a digitised voice clip saying 'my location' . 

40 

As a refinement of this technique, the Mobile Station could have a role as a conamand 
formatter with the commands being selected by the end-user using man-machine interface 
menus, radio buttons, etc. The Mobile Station would then generate the corresponding 
command and include in the message user data. This could be achieved today using various 
45 combinations of technology such as Wireless Application Protocol Wireless Telephony 

Application (WTA), J2ME or SIM AppUcation Toolkit to accept command requests via the 
man-machine interface in a programmable manner and translate them for inclusion in the 
message. Again, because these types of interface are programmable and downloadable 
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from the central server only the central server is impacted when additional commands are 
added, the program interpretation interfaces on the Mobile Station remaining fixed. 

Finally, it is noted that the basic mechanism described above could be expanded to allow 
5 the use of such commands with other types of value-added services e.g. CAMEL or IN 

services, for easy pre-paid service credit refill or for the control of service options such as 
VPN forwarding settings, etc. Because this is the case, the name "Service Control 
Commands" is given to these embedded message user data commands. Note that the 
identity of the party originating the message and the specific Service Control Command 
10 will for example normally be used by the Application called for those Service Control 
Commands relevant to such network services. This is in order to modify the message 
destination address such that it can be routed to the appropriate IN or CAMEL server that 
the message originating party is registered at and which contains the originating party's 
subscription details. 

15 

Some attempts have been made in prior art to enable a subscriber to monitor and govem 
routing of circuit-related telephone calls. EP,A1, 651 548, for example, reveals a system for 
routing telephone calls in which a dialled telephone number is translated into a routing 
number according to instructions from a database maintained by a telephone subscriber. 

20 This system enables a subscriber to customize and maintain its own database for the 

routing of circuit-related telephone calls made in telephone networks supporting Intelligent 
Network systems. The system is call related, and the central database only handles the 
flexible setup of the signaUing virtual circuit and associated speech path towards one of 
many destinations via translation of the dialled number into a routable number, under 

25 operator and/or subscriber control. WO,Al, 94/29992 reveals a system and method for 
providing a subscriber with the ability to screen and route incoming circuit-related calls 
based on the role or function associated with the numbers dialled by a calling party. 

The major difference from presented prior art, besides that present invention deals with 
30 routing of datagram messages and not of circuit-related telephone calls, is that present 
invention does not translate the number at the network database to point out the 
destination. The present invention, as will become more apparent by the following 
description, instead redirects a message to an intermediate node using a preset number 
associated with the combination of services that shall be operated upon the terminating 
35 message, preserving the origin and destination numbers. This enables the ability to 

transparently intercept, analyse, modify and then route the datagram message to the original 
receiver. 

40 Objects of the Invention 

One object of the present invention is to make the network handling of Service Control 
Cormnands possible at all times and with all Mobile Stations supporting a messaging 
service, to a subscriber of services in a mobile radio network. 

45 Another object of the invention is to make the network formatting, onward routing, 

termination and response handling of mobile messages conditional upon both the command 
being analysed and a fixed set of message parameters, the semantic interpretation of which 
are govemed by the identity of the Service Control Command. 
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Another object of the invention is to allow for direct entry by the subscriber of Service 
Control Commands, such that neither the Mobile Station nor any network node other than 
the Message Handling Centre need be updated in order to process the entered command 
5 successfully. 

Yet another object of the present invention is to allow for the subscriber to enter Service 
Control Commands via a remotely programmable interface on the Mobile Station, such that 
the man-machine interface on the Mobile Station can be changed at the request of the 

10 Message Handling Centre or other coordinated network node. Li this case, the 

transformation of the data entered in man-machine interface data entry format into Service 
Control Command format and the subsequent inclusion of the translated command into the 
user data part of a message is defined by the downloaded program. In this way, neither the 
Mobile Station nor any network node other than the Message Handling Centre need to be 

15 updated in order to process the entered Service Control Commands successfully. 

Yet another object of the present invention is to allow the Message Handling Centre to 
execute internal or external hardware/software functions (Applications) to process the 
received Service Control Command. 

20 

Disclosure of the Invention 

According to the invention, the stated objects are met by a method of handling Service 
Control Command entry and the incorporation of one or more Service Control 

25 Command(s) into message user data. The Mobile Station (or user equipment for UMTS) 
transmits messages containing user data (provided that the end-user has a valid network 
subscription) to a Message Handling Centre via a mobile radio network, the mobile radio 
network being part of a mobile radio communication system. The Message Handling 
Centre has the capability of receiving and processing the message, of being associated with 

30 different internal and/or external hardware/software Applications and of exchanging data 
with these Applications via internal or external protocols. 

In the inventive method, the end user either enters Service Control Commands into 
message user data directly or indirectly via Mobile Station man-machine interface 

35 comotnands, which are then translated into Service Control Commands and inserted into the 
message user data. The Service Control Command(s) embedded in the message user data 
are sent from the Mobile Station to the Message HandUng Centre, which parses the 
message user data. If a Service Control Command is found by this parsing, the Message 
Handling Centre formats the Service Control Command data appropriately, and relays it to 

40 the Application associated with the Service Control Command. Note that the Message 

Handling Centre will handle each command in different ways. For instance, if a location is 
to be appended to a Mobile Station originated message then the Message Handling Centre 
will send the Service Control Command to the Application (which may be trusted and 
collocated or extemal and 3'^ party) using an appropriate protocol; the Application will 

45 retrieve the terminal location. If the whole message user data was passed, it can insert the 
location itself in the message and pass it back to the message service centre for onward 
routing. Otherwise, if passing of all of the user data is not possible the Application will 
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pass the location back to the Message Handling Centre for insertion into the message at the 
desired point. 

The objects of the invention are further met by the specification of a basic Service Control 
Command set. The minimum prerequisite for the command set is that command 
specification using text shall be possible in order to ensure ubiquitous usage of the system, 
with optional audio and graphical command specifications being possible when applicable. 
An illustrative example of a Basic Service Control Command Set with text and audio 
commands is given in figure 1. No examples of graphics are being given, which does not 
preclude their use. 

For all of the text and audio commands, it is assumed that the message user data may be in 
any media format, and that at least two parts of user data in different formats may be 
carried. Inclusion of message text or other media (picture, voice message, etc) is optional 
for some services but mandatory for others e.g. pre-paid refill and balance enquiry, and it is 
left to the Application and/or end-user to decide on inclusion. Entry of the message user 
data per se is not detailed in the audio commands above. 

The Mobile Station is associated with a subscription to messaging services, said 
subscription having the possibiUty of being associated with different Mobile Stations at 
different times. The Mobile Station comprises a Subscriber Identity Module (SIM) with 
message sending and receipt capabilities for storing Mobile Station phonebook contents, 
and optionally a WAP browser with WTA user agent and repository or an ME and SIM 
that supports the SIM Application Toolkit or aJ2ME execution environment. Optionally 
the Mobile Station may be divided into two parts. The first part comprises a mobile 
equipment part that has battery, man machine interface, control circuitry and radio 
interface, etc. The second part comprises a Subscriber Identity Module, containing 
subscribe specific control algorithms and data. 

The inventive system for mobile radio communication comprises a first server section 
comprising a server containing a Message Handling Centre for analysis and modification of 
received messages, the first server section also for sending the received messages to a 
destination Mobile Station or Application as a result of routing analysis based on message 
destination address and Service Control Command(s). The inventive system further 
comprises a second server section containing Applications for operating on Service Control 
Commands received from the Message Handling Centre, the second server section also 
returning the results of this operation to the Message Handling Centre in the first server 
section. The inventive system further comprises optionally a third server section for storage 
and downloading of programs to the Mobile Station for the translation of terminal-specific 
input data into Service Control Command(s) using Mobile Station-based execution 
environments such as J2ME, SAT or WAPAVTA. These conmiands are then sent to the 
Message Handhng Centre in the first server section. In the inventive system, the Mobile 
Equipment repository or the SIM optionally comprises storage for default Service Control 
Commands. The first, second and third server sections could be logically and/or physically 
co-located, or located at separate servers. 
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Brief Description of the Drawings 

FIG. 1 illustrates an example table of a Basic Service Control Command Set with given 

text and audio conamands; 
HG. 2 illustrates the general topology of a GSM network, showing the network functions 

that are necessary in order to route short messages; 
HG. 3 illustrates an example of Mobile Messaging showing Application Invocation by 

Service Control Commands; 
FIG. 4 illustrates an example table of Basic Service Control Command analysis/actions at 

the Message Handling Centre and Applications; 
FIG. 5a illustrates MO Message Reception HandUng; 
FIG. 5b illustrates Message Handling Centre Invocation; 
FIG. 5c illustrates Message Report Handling; 
FIG. 5d illustrates Application Report Handling; 
FIG. 5e illustrates GSM Report Handling; 
FIG. 5e illustrates Outgoing Route Analysis. 



Description of the Preferred Embodiments 

In the inventive method, the end-user either enters Service Control Conomands into 
message user data directly or indirectly via Mobile Station man-machine interface 
commands, which are then translated into Service Control Commands and inserted into the 
message user data. The Service Control Command(s) embedded in the message user data 
are sent from the Mobile Station to the Message Handling Centre, which parses the 
message user data. If a Service Control Command is found by this parsing, then the 
Message Handling Centre formats the Service Control Command data appropriately, and 
relays it to the Apphcation associated with the Service Control Command. 

In one embodiment of the inventive method, the user directly enters the Service Control 
Command into the message user data, and the transfer of data between the Mobile Station 
and the Message Handling Centre is performed under user control using only basic Mobile 
Station messaging capabilities. 

In one embodiment of the inventive method, the Mobile Station comprises a Wireless 
Telephony Apphcation (WTA) user agent, and the transfer of data between the Mobile 
Station and the Message Handling Centre can be performed by use of the Wireless 
Apphcation protocol (WAP). In this embodiment, the WTA text message sending 
capability could be utihsed to provide a WAP-based message sending capability witii an 
advanced API that gives the user access to the phonebook or group Usts as well as to a Ust 
of Service Control Commands that can be optionaUy included and/or set up as messaging 
defaults. Storage of the defaults in the WTA repository would give the WTA-based MMI a 
persistent memory of Service Contiol Command settings. 

In one embodiment of the inventive method, the Mobile Station/user equipment is 
equipped with GSM/UMTS SIM Apphcation Toolkit (SAT) capabiUties, and tiie transfer 
of data between the Mobile Station/user equipment and the Message Handhng Centre can 
be performed by use of the SAT procedures. In this embodiment, the SAT short message- 
handUng capability could be utiMsed to provide a SAT-based message sending function 
incorporating an advanced API giving the user access to the phonebook as well as to a hst 
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of Service Control Commands that can be optionally included and/or set up as messaging 
defaults, as weU as allow receipt of delivery reports. Storage of the defaults in the SIM or 
USIM vvould give the SAT-based MMI a persistent memory of Service Control Command 
settings. 

The inventive system for subscriber-controlled processing and routing of messages and 
service requests in a mobile radio communication system comprises a first server section 
comprising a server containing a Message Handling Centre for analysis and modification of 
received messages, the first server section also for sending the received messages to a 
destination Mobile Station or Application as a result of routing analysis based on message 
destination address and Service Control Command(s). The inventive system further 
comprises a second server section containing Applications for operating on Service Control 
Commands received from the Message Handling Centre, the second server section also 
returning the results of this operation to the Message Handling Centre in the first server 
section. The inventive system further comprises optionally a third server section for storage 
and downloading of programs to the Mobile Station for the translation of terminal-specific 
input data into Service Control Command(s) using Mobile Station-based execution 
environments such as J2ME, SAT or WAP/WTA. These commands are then sent to the 
Message Handling Centre in the first server section. In the inventive system, the Mobile 
Equipment repository or the SIM optionally comprises storage for default Service Control 
Commands. The first, second and third server sections could be logically and/or physically 
co-located, or located at separate servers. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a Service Control Command embedded in message user data 
requesting the inclusion of the message sending party's location in the message. On 
analysis, the first server section shall communicate with the second server section. The 
second server section shall further analyse the message originating party and message- 
receiving party in order to ascertain that the originating party allows his/her location to be 
sent to the destination party. If the analysis indicates that this is allowed, the second server 
section obtains the location of the message sending party. This location shall for example 
be in coordinate or textual description form and shall be included in the message in a 
suitable media format by replacement of tiie location request. The first or second server 
section, dependant upon the protocol used between them, can either perform this inclusion. 

In one embodiment of the inventive system said first server section comprises Service 
Contirol Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a Service Control Command embedded in message user data 
requesting the inclusion of the message-receiving party's location in a response message to 
be sent back to the message sending party. On analysis, the first server section shall 
communicate with the second server section. The second server section shall further 
analyse the originating message originating party and message-receiving party in order to 
ascertain that the destinationecond server section sion to send location can also be 
performed in the first server sect the destination party. If t party allows his/her location to 
be sent to the originating party. If the analysis indicates that this is allowed, the second 
server section obtains the location of the message-receiving party. This location shall for 
example be in coordinate or textual description form and shall be included in the response 
message in a suitable media format and at a suitable point in the returned user data. The 
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first or second server section, dependant upon ttie protocol used between them, can either 
perform this inclusion. 

In one embodiment of the inventive system said first server section comprises Service 
5 Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a Service Control Command embedded in message user data 
indicating that the message-receiving party is allowed to locate the message sending party. 
On analysis, the first server section shall communicate with the second server section in 
order to set the location preference for the message receiving party with respect to being 
10 allowed to locate the message sending party. Upon successful setting of the message- 
receiving party's preferences by the second server segment then the second server segment 
may either terminate message sending by request to the iBrst server segment or request the 
first server segment to send the message to the message-receiving party. If sent, the 
message may have the original message user data replaced by user data in a suitable media 
15 format (text, audio, graphic) indicating that the message-receiving party is able to locate the 
message sending party. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 

20 types including text, a Service Control Command embedded in message user data 

indicating that the message-receiving party is not allowed to locate the message sending 
party. On analysis, the first server section shall communicate with the second server section 
in order to set the location preference for the message receiving party with respect to being 
not allowed to locate the message sending party. Upon successful setting of the message- 

25 receiving party's preferences by the second server segment then the second server segment 
may either terminate message sending by request to the first server segment or request the 
first server segment to send the message to the message-receiving party. If sent, the 
message may have the original message user data replaced by user data in a suitable media 
format (text, audio, graphic) indicating that the message-receiving party is not able to 

30 locate the message sending party. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a Service Control Command embedded in message user data 

35 indicating that the destination party indicated in the message is to be located by the 

message sending party. On analysis, the first server section shall communicate with the 
second server section in order to ensure that the message sending party is allowed to locate 
the message receiving party. If location is allowed, the message receiving party is located. 
This location shall for example be in coordinate or textual description form and shall be 

40 included in the response message in a suitable media format and at a suitable point in the 
returned user data. The first or second server section, dependant upon the protocol used 
between them, can either perform this inclusion. 

In one embodiment of the inventive system said first server section comprises Service 
45 Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a request embedded in message user data requesting that a check of 
the pre-paid account balance of party indicated by destination address be performed. On 
analysis, the first server section shall conununicate with the second server section. The 
second server section shall then analyse the message originating party's address in order to 
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ascertain the address of the network node holding the message-receiving party's pre-paid 
account details. The second server section shall then request the first server section to 
forward the message with the message destination address set to the address of the network 
node containing the pre-paid account balance and the message user data holding the 

5 command followed by the original message destination address. In this embodiment, it is 
the responsibility of the network node holding the pre-paid account balance to validate the 
message sender and then to retrieve the pre-paid account balance. Pre-paid account balance 
inclusion in a message response sent to the message sending party shall then be performed. 
This account balance shall for example be in graphical or textual description form and shall 

10 be included in the message in a suitable media format, at a suitable point in the message. 
The network node holding the pre-paid account balance shall perform this inclusion. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 

15 types including text, a request embedded in message user data requesting that a refill of the 
pre-paid account balance of party indicated by destination address be performed. On 
analysis, the first server section shall communicate with the second server section. The 
second server section shall then analyse the message originating party's address in order to 
ascertain the address of the network node holding the message-receiving party's pre-paid 

20 account details. The second server section shall then request the first server section to 

forward the message with the message destination address set to the address of the network 
node containing the pre-paid account balance and the message user data holding the 
conunand followed by the original message destination address. In this embodiment, it is 
the responsibility of the network node holding the pre-paid account balance to validate the 

25 message sender and then to add to the pre-paid account the monies indicated by the 

validated refiU amount. Resultant pre-paid account balance inclusion in a message response 
sent to the message sending party may then optionally be performed. This account balance 
shall for example be in graphical or textual description form and shall be included in the 
message in a suitable media format, at a suitable point in the message. The network node 

30 holding the pre-paid account balance shall perform this inclusion. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a Service Control Command embedded in message user data 

35 indicating that the message-receiving party is allowed to receive presence information 

(subscriber reachable/not reachable) pertaining to the message sending party. On analysis, 
the first server section shall communicate with the second server section in order to set the 
presence preference for the message-receiving party with respect to being allowed to obtain 
the message sending party' s presence status. Upon successful setting of the message- 

40 receivmg party' s preferences by the second server segment then the second server segment 
may either terminate message sending by request to the first server segment or request the 
first server segment to send die message to the message-receiving party. If sent, the 
message may have the original message user data replaced by user data in a suitable media 
format (text, audio, graphic) indicating that the message-receiving party is able to receive 

45 presence information pertaining to the message sending party. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a Service Control Command embedded in message user data 



wo 03/088688 



PCT/SE03/00583 



10 



indicating that the message-receiving party is not allowed to receive presence information 
(subscriber reachable/not reachable) pertaining to the message sending party. On analysis, 
the first server section shall communicate with the second server section in order to set the 
presence preference for the message-receiving party with respect to not being allowed to 
obtain the message sending party's presence information. Upon successful setting of the 
message-receiving party's preferences by the second server segment then the second server 
segment may either terminate message sending by request to the first server segment or 
request the first server segment to send the message to the message-receiving party. If sent, 
the message may have the original message user data replaced by user data in a suitable 
media format (text, audio, graphic) indicating that the message-receiving party is not able 
to receive presence information pertaining to the message sending party. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a request embedded in message user data for the notification of the 
message sending party when the destination party attaches to the network and thus becomes 
reachable for communication. On analysis, the first server section shall communicate with 
the second server section. The second server section shall check that the message 
originating party can obtain presence information for the message receiving party. If he/she 
can do this then the second server segment registers the message sending party's request 
for destination party availability. This Application shall monitor the message destination 
party for presence in the network, and when the message destination party's state is noted 
to be attached (which may be immediate) the second server section shall via the first server 
section send a message response to the message originating party indicating that the 
message destination party has attached to the network. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a request embedded in message user data requesting the storage in the 
second server section of user defined data. This data pertains to the message originating 
party for inclusion in message user data when the message originating party subsequentiy 
requests this. On analysis, the first server section shall communicate with the second server 
section in order to pass it the user-defined data pertaining to the message sending party. 
This user-defined data shall for example be in graphic, audio or textual description form 
and shall be included in the message user data by the sending party in a suitable media 
format, for storage in the second server segment AppUcation. Note that any message 
destination address may be entered in the message as this Service Control Command 
results in analysis of the message originating address only. The message shall not be 
forwarded to the destination address after analysis by the first server segment. 

In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabiUties allowing it to recognise, for one or more media 
types including text, a request embedded in message user data requesting the inclusion of 
the message sending party's user-defined data in the message. On analysis, the first server 
section shall communicate with the second server section in order to obtain the user- 
defined data pertinent to the message sending party. This user-defined data shall be 
included in the message in a suitable media format by replacement of the user-defined data 
inclusion request. The first or second server section can either perform this inclusion. 
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In one embodiment of the inventive system said first server section comprises Service 
Control Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a request embedded in message user data to the copy the message to 
the sending party's e-mail address. The e-mail address can either be eaitered by the sending 
party in the message user data or stored on the first server section. On analysis, the first 
server section shall communicate with the second server section in order to forward the 
message as e-mail to the mailbox of the message sending party. 

In one embodiment of the inventive system said first server section comprises Service 
Contirol Command analysis capabilities allowing it to recognise, for one or more media 
types including text, a request embedded in message user data requesting sending of the 
message in real-time only to the message destination party i.e. the message shall not be 
stored for later forwarding. If the message cannot be delivered then the message sending 
party shall be notified and the second server section Application shall monitor tiie message 
destination party for presence in the network. When the message destination party's state is 
noted to be attached (which may be inomediate) the second server section shall via the first 
server section send a message to the message originating party indicating that the message 
destination party has attached to the network. 



As noted in the Disclosure chapter, tiie Service Conti-ol Command method described is 
applicable to all networks where messaging is possible between a mobile network terminal 
and another terminal or Application, for the exchange of user data in a defined media 
format. This section shall concentrate on illustrating an example implementation of the 
metiiod in the GSM network, as this is widely used and well understood. 

The GSM short message tele-service as defined in the GSM standard can be used to send 
messages between defined end-points. Such an end-point is called a Short Message Entity 
(SME). SMEs must be capable of handling message reception, processing and if necessary 
response syntactically and semantically. SMEs can eitiier be GSM Mobile Stations or any 
other function or device known herein as an AppUcation. The messaging permutations 
allowed by the GSM standard are: 

• From Message Originating Mobile Station (MO MS) to Mobile Terminating 

Mobile Station (MT MS) 

• From MO MS to Application 

• From Application to MT MS 

Note tiiat because SMEs are defined as end-points the GSM standard dictates that the 
Application must be addressed using a message destination address or origination address. 
The message can be transferred between SMEs using packet- or circuit-based bearers. 
Functionally the deUvery of messages from the SME to the Short Message Service Centire 
(SMSC) is handled asynchronously with respect to the deUvery of messages from the 
SMSC to the SME. 

Figure 2 illustirates the general topology of a GSM network, showing tiie network functions 
that are necessary in order to route short messages. As shown, the clouds represent 
combined GSM core and access networks. The diagram shows two such networks, to each 
of which is shown attached to an MS. Each network is shown as being attached to an 
SMSC. The SMSC is usually operated by tiie network operator to whose network the MO 



wo 03/088688 



PCT/SE03/00583 



12 



MS belongs, but it must be emphasized that this need not be the case i.e. in cases where the 
SMSC belongs to a 3"^*^ party Application provider. The dashed lines separating the 
networks from the messaging centre itself show this separation of network functions from 
SMSC. Note that in the case where the subscriber is roaming in the Home Public Land 
5 Mobile Network (HPUVIN) network operators 1 and 2 are the same for MO short message 
submission to the SMSC, and network operators 2 and 3 are the same for MT short 
message delivery by the SMSC. 

For the case of message submission to an SMSC from an MS in a GSM network the 
10 message is passed from the MS through the access network to either an SGSN (packet 
access) or MSC (circuit access). The MSC checks with its collocated VLR that message 
submission from the MS is allowed, and if it is then the message is submitted to the SMSC 
via an SMS inter-working MSC (SMS-IWMSC) using an SMS-SUBMIT relay layer 
component carried in a MAP MO-Forward SM message. The subscription information held 
15 at the VLR is transmitted to it from the HPLMN Home Location Register (HLR) when the 
GSM Location Update, Data Insertion or Data Restoration procedures are performed. The 
SMSC address is held in the GSM Subscriber Information Module (SIM), but may be 
changed by the owner of the SIM via the MS (Man-Machine Interface (MMI) or by remote 
provisioning using the 3GPP GSM/UMTS SIM data download facility. Note that if this is 
20 done then the operator of the SMSC addressed by the new entry should have already 
authorized access to it by the owner of the MS. 

In the case of message submission to the SMSC by AppUcation, one of a number of 
proprietary or industry-standard protocols may be used. An example is the SMEP protocol. 
25 These protocols are based on HTTP or XML and are mostly extensible via the addition of 
messages and parameters. Because the AppUcations are SMEs, they must be addressed by 
MSISDN as network message destinations. 

For the case of message deUvery by an SMSC to an MS in a GSM network the message is 
30 passed to the MS through the access network by either an SGSN (packet access) or MSC 
(circuit access). In order to access one of these nodes the SMSC first delivers the message 
to an SMS-GMSC. The SMS-GMSC function checks with the home network HLR that 
message delivery to the MS is allowed by use of the MAP message Send Routing 
Information for Short Message, and if it is then the message is submitted by the SMS- 
35 GMSC using an SMS-DELIVER relay layer component carried in a MAP MT-Forward 
SM message to either an SGSN or MSC. If delivery fails or is not allowed by the HLR, a 
negative response is sent to the SMSC by the SMS-GMSC and the message may 
(dependant upon whether delivery reattempt is required) be stored for later delivery by the 
SMSC. In this latter case, either the SMSC resends the message at periodic intervals until 
40 sending is successful, or (in the case of the MS being detached from the network) the SMS- 
GMSC sends a Delivery Report Status message to the HLR requesting the HLR to inform 
the SMSC of terminal reactivation. This is done by the HLR sending an SMS Alert 
message to the SMSC when the MS reattaches to the network. 

45 In the case of message delivery to the SMSC by an Application, one of a number of 

proprietary or industry-standard protocols may be used. An example is again the SMPP 
protocol. These protocols are based on HTTP or XML and are mostly extensible via the 
addition of messages and parameters. Because the Applications are SMEs, they must set 
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the message origination address as their own MSISDN, and the receiving MS as the 
network message destination. 

The previous description of the routing principles apphed to GSM short messages showed 
5 firstly that Applications are treated as end-points for message initiation and receipt by other 
end users of the GSM short message service. This means that: 

• Application identities must be included in short messages as destination addresses, 
entered directly or from the phonebook. 

• Messages cannot be easily relayed via Applications to destinations, because the 
10 destination address is occupied by the Application address and the phonebook 

cannot easily be used to insert numbers into user data with standard GSM Mobile 
Stations. 

As shown in Figure 3, Service Control Commands can be used to allow such a message 
15 relay via invocation of Applications for messages destined for other destination addresses, 
these indicating either Mobile Stations or other Applications. The message flows for the 
message submission to the SMSC and subsequent delivery to the terminating Application 
or MS are the same as described previously. However upon receipt of a submitted message 
by the SMSC the user data is passed to the Message Handling Centre and parsed, and if a 
20 Service Control Command is encountered then it is interpreted and the Application 

associated with it is invoked. In the event of more than one Service Control Command 
being invoked it is possible to either invoke one Application to handle all commands, or to 
invoke more than one Application with each Application handling one or a set of 
commands. The External Server function shown in Figure 3 is used by the Applications to 
25 collect information from the network pertinent to the successful execution of the Service 
Control Command. Thus the External Server may be a Location Server, a Presence Server, 
an e-mail server, etc. 

It is assumed herein that the SMSC to Application protocols shall allow the carriage of 
30 Service Control Command information either explicitly or implicitly. In the former case, an 
AppUcation shall be able to handle the interpretation of multiple Service Control 
Commands on receipt in user data. In the latter case, the Application shall be run for 
specific, fixed single Service Control Commands or sets of Service Control Commands. It 
is not the intention of this method to place any constraints over the protocol, save that the 
35 Application should be able to be passed enough information such that it can act upon 
Service Control Commands correctly. 

An example of command interpretation is illustrated in the Figure 4, for some of the many 
possible routing selection mechanisms that could be incorporated into the Message 

40 Handling Centre. Note that the partitioning of command handling functionality can be done 
in such a way as to make the Message HandUng Centre statefuU or stateless behaviour with 
respect to Application interactions. The tabular representation shown illustrates a stateless 
Message Handling Centre, and the reader should note that the Service Control Command 
analysis functions could also be implemented using tree- or list-based structures. Note also 

45 that the AppUcation identities are referred to by Application addresses 1 to 6 in the table 

only in order to match those shown in Figure 3, and in no way should be taken as implying 
a fixed link between Service Control Commands and Application addresses, or 
Applications and the functionality they contain. The assumed implementation does contain 
internal state behaviour in order to handle the modification of message reports, etc as a 
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result of earUer AppUcation invocation, for use when appending receiver destination 
address to the SMS Delivery Report, etc. 

As can be seen from Figure 4, the proposal for realization of the stateless functionality of 
the Message Handling Centre within an SMSC is both invariant with respect to command 
type and simple to implement. All of the variable logic is contained within the 
Applications, with the variable parts of the Message Handling Centre confined to data 
entries in end-user controlled data, containing parameters such as destination address and 
Service Control Command keywords, network controlled data such as IMSI, IMEI, Time, 
Location for message originating and destination parties. These data structures allow the 
evaluation of these input parameters to produce a destination address and route type. The 
AppHcation addresses are just a type of destination address, and in the outbound 
destination analysis the route type can be used to select the protocol to be used to send the 
message to the Application i.e. SMPP, GSM short messaging. 

It should be noted that the interpretation of all Service Control Commands can be done 
sequentially if the Applications remove the command(s) that they have been invoked to 
handle. Indeed, as noted previously in the table the outbound routing analysis can select 
destinations and corresponding routes based on a combination of user defined addresses, 
data, locations, times, etc. The messages received firom the Applications are subjected to 
route analysis in the same way as messages received from the message originating party 
and are thus treated as message originating parties, allowing Applications to insert their 
own Service Control Commands for distributed AppHcation execution. 

Figure 5 details the successful handling of messages in the SMSC, showing the 
involvement of the Message-Handling Centre. For simpUcity, error cases are not shown in 
these diagrams. 

One skilled in the art will appreciate that the present invention is not limited to the 
embodiments disclosed in the enclosed drawings and the foregoing description, which are 
presented for purposes of illustration only, but it can be implemented in a number of 
different ways, as defined by the following claims. 

It should be appreciated by those skiUed in the art that the conception and specific 
embodiment disclosed might be readily utilised as a basis for modifying or designing other 
structures for carrying out the same purposes of the present invention. 

It should also be realised by those skilled in the art that such equivalent constructions do 
not depart from the spirit and scope of the invention as set forth in the appended claims. 
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CLAIMS 

1. A method for end-user controlled processing and routing of messages in a mobile 
radio communication system, characterised by the steps of: 

defining at a central message processing point, the Message Handling Centre,: 

rules governing message routing analyses based on the presence and content 
of: 

end-user defined data including Service Control Command(s), message 
originating address or identity, message destination address or identity, 
message length or content; and/or 

network defined data including time, IMSI, IMEI, message originating 
and/or terminating location; and 

type of routing to be applied as a result of a particular routing analysis, 
including whether to modify data sent back to the message originator in 
subsequent message submit or status reports and what communication 
methods to use towards the message destination obtained as a result of 
analysis; 

including Service Control ConQmand(s) and/or other end-user defined data in a 
message; 

sending the message; 

receiving sent message at the Message Handling Centre, where the message is 
parsed and analysed; and 

routing the message in accordance with the result of the parsing and routing 
analysis to an Application associated with the Service Control Conmiand(s) and/or 
routing rules, or onwards to a message destination point. 

2. Method as claimed in claim 1 including the steps of: 

performing modification of the contents of a subsequently received message report 
in order to insert Application-derived data into a submitted message deliver or 
message status report; and 

transmitting such reports to the message originator. 
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3. Method as claimed in claim 1, wherein the inclusion of Service Control 
Command(s) in the message is performed by: 

a message originating subscriber directly by text, voice, dedicated buttons, touch 
pad, menu or graphical interface; or 

a programmable man-machine interface, such as Wireless Telephony Application 
(WTA), GSM/UMTS SIM Application Toolkit (SAT) or J2ME, which generates 
the command(s) aad includes them into the message; or 

a message originating messaging Application. 

4. A method as claimed in claim 1, wherein the parsing and analysing of the message 
includes recognising, for one or more message media types including text. Service 
Control Command(s) included in the message, interpreting included Service 
Control Command(s) and possibly modifying/formatting one or several of the 
included Service Control Command(s). 



5. A method as claimed in claim 1 including the step of (re-) routing the results of the 
operation(s), such as requested service information, a modified message and/or 
modified Service Control Command(s), from the Application to a message 
destination point, the message originating point, another Application or to the 
Message Handling Centre for onward routing, wherein the result can be (re-) routed 
as a part of the original message, if the whole message was routed to the 
Application in the first place, or separate for insertion into the message at a desired 
point, if only the Service Control Command itself was routed to the Application. 

6. A method as claimed in any preceding claim, wherein the message can be of a 
SMS-, WAP-, or GSM/UMTS SIM AppUcation Toolkit (SAT)-type. 

7. A method as claimed in claim 3 or 6, wherein the API incorporated in the WAP- 
and SAT-based messaging type enables use of Service Control Command lists that 
can be optionally included and/or set up as messaging defaults for easy handling 
and inclusion of Service Control Command(s) in messages. 

8. A method as claimed in any preceding claim, wherein the Service Control 
Command is associated with presence specific services, such as: 

allowing message-destination party to obtain presence information pertaining to 
message sending party, for example by including the character combination .AA 
(Attach Allow) in the message; or 
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disallowing message-destination party to obtain presence information pertaining to 
message sending party, for example by including the character combination .AD 
(Attach Disallow) in the message; or 

5 

requesting notification when party identified by destination address attaches to 
network, for example by including the character combination .A (Attach) in the 
message. 

10 

9. A method as claimed in any preceding claim, wherein the Service Control 
Command is associated with location specific services, such as: 

appending message-originating party's location to sent message, for example by 
15 including the character combination .M (My location) in the message; or 

appending message-destination party's location to message delivery response, for 
example by including the character combination .DL (Deliver and Locate) in the 
message. 

20 

10. A method as claimed in any preceding claim, wherein the Service Control 
Command is associated with pre-paid specific services, such as: 

25 checking pre-paid account balance of party indicated by destination address, for 

example by including the character combination .B TIN' (Balance PIN, e.g. syntax 
.B 4589) in the message; or 

refilling pre-paid account of receiver indicated by destination address, for example 
30 by including the character combination .R 'Voucher number' (Refill 'Voucher 

number', e.g. syntax .R 15885556) in the message. 



11. A method as claimed in any preceding claim, wherein the Service Control 
35 Command is associated with services concerning friends, their location and their 

presence, such as: 

inviting the party indicated by the message destination address to join the message 
originating party's friend list, for example by including the character combination 
40 .1 (Invite) in the message; or 

allowing the party indicated by the message destination address to receive the 
message originating party's location, for example by including the character 
combination .LA (Location Allowed) in the message; or 



45 



disallowing the party indicated by the message destination address from receiving 
the message originating party's location, for example by including the character 
combination .LD (Location Disallowed) in the message; or 
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locating the party indicated by the message destination address without sending a 
text naessage, for example by including the character combination .L (Locate) in the 
message; or 

5 sending a message in real-time to the party indicated by the message destination 

address and, if the message cannot be delivered, notifying the party originating the 
message and setting a request for that party to be notified when the party indicated 
by the message destination address attaches to the network, for example by 
including the character combination .R (Real time) in the message. 

10 

12. A method as claimed in any preceding claim, wherein the Service Control 
Conmiand is associated with user-defined message items, such as: 

15 appending user-defined item (e-mail address, web address, etc) to message, for 

example by including the character combination .U (User) in the message; or 

defining user-defined item, for example by including the character combination .D 
'Item' (User 'Item', e.g. syntax .D ' www.mQbilearts.se ' or .D 'Paul is at .M') in the 
20 message. 

13. A method as claimed in any preceding claim, wherein the Service Control 
Command is associated with user-defined message items, such as: 

25 

sending copy of the message to the message originating party's e-mail address, for 
example by including the character combination .C (Copy) in the message. 

30 14. A System for end-user controlled processing and routing of messages in a mobile 

radio communication system, comprising: 

a first server section containing a Message Handling Centre with means for: 

35 receiving and storing rules governing message routing analyses based on the 

presence and content of: 

end-user defined data including Service Control Command(s), message 
originating address or identity, message destination address or identity, 
40 message length or content; and/or 

network defined data including time, IMSI, IMEI, message originating 
and/or terminating location; and 

45 parsing and analysing received messages; and 

modification and routing of received messages in accordance with the result 
of the parsing and routing analysis to a second server section associated with 



wo 03/088688 



PCT/SE03/00583 



19 

the Service Control Coniinand(s) and/or routing rules, or onwards to a 
message destination point 

a second server section containing one or several Applications associated with and 
5 operating on Service Control Commands and/or routing rules received from the 

Message Handling Centre. 

15. System as claimed in claim 14, characterised in that the Message HandUng Centre 
10 in the first server section consists of a short message service centre, a multi-media 

messaging service centre or an e-mail server, with additional internal and/or 
external hardware/software. 

15 16. System as claimed in claim 14, characterised in that the second server section also 

comprises means for (re-) routing the results of the operation(s), such as requested 
service information, a modified message and/or modified Service Control 
Command(s), to a message destination point, to the message originator point, to 
another Application or to the Message Handling Centre in the first server section 

20 for onward routing, the result as a part of the original message, if the whole 

message was routed to the Application in the first place, or separate for insertion 
into the message at a desired point, if only the Service Control Conoutnand itself was 
routed to the Application. 

25 

17. System as claimed in claim 14, characterised in that the system further comprises a 
third server section with means for: 

storage and downloading of programs to mobile terminals for the translation of 
30 terminal-specific input data into Service Control Command(s) using mobile 

equipment-based execution environments such as J2ME, SAT or WAP/WTA; and 

sending these commands to the Message Handling Centre in the first server section. 

35 

18. System as claimed in claim 17, characterised in that default Service Control 
Commands are stored in the mobile terminal repository or SIM. 

40 19. System as claimed in any preceding claim 14-18, characterised in that the first, 

second and third server sections could be logically and/or physically co-located, or 
located at separate servers, exchanging data with appropriate internal or extemal 
protocols. 



45 
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20. System as claimed in any preceding claim 14 -19, characterised in that it further 
comprises means for: 

performing modification of the contents of a subsequently received message 
dehvery report in order to insert Application-derived data into a submitted message 
delivery or message status report for transmission of such reports to the message 
originating party; and/or 

changing the destination address or identity to modify onward routing of the 
message; and/or 

reformatting the message; and/or 
adding elements to the message; and/or 

deleting the Service Control Command(s) or message and sending a response; 
and/or 

terminating the message and sending a response; and/or 
interacting with other network services. 

21. System as claimed in any preceding claim 14 - 20, characterised in that included 
server sections in combination comprises means for processing and routing service 
requests, messages and service responses concerning: 

presence specific services; and/or 
location specific services, and/or 

pre-paid specific services; and/or 

friends specific services, their location and their presence; and/or 
user-defined specific services. 

22. A computer program product having a computer readable medium with computer 
program logic recorded thereon for use in a system for providing services based on 
Service Control Conmiands and/or routing rules comprising means for: 

receiving and storing rules governing message routing analyses; and 

parsing and analysing received messages; and 

formatting, modifying and routing said data according to routing rules and parsed 
and analysed Service Control Commands to an Application associated with the 
Service Control Command(s), or onwards to a message destination point. 
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Service Control 
Coinmand(s) 



Application 
invoked 



Action at the SMSC/Message 
Handling Centre 



Action at the Application 



Append 

originator's 

location 



Send Deliver message 
containing Submit message user 
data to Application on receipt 
from originating party of Submit 
message with destination 
address set to Application 
address, and set message 
extension field = received 
message destination address. 

Relay subsequently received 
Delivery Report message user 
data to originating party, in 
SMS-Submit Report message. 

Relay subsequently received 
application-originated Submit 
message to the indicated 
destination address resulting 
from outgoing routing analysis, 
handling subsequently received 
Delivery Reports or Status 
Reports in the standard defined 
manner. 



Retrieve originating party location from 
network 1 via external location server, 
using originating party address in 
received message. Include retrieved 
location data in Delivery Report message 
user data in place of append originator's 
location Service Control Command. 

Send Delivery Report to Message 
handling Centre/SMSC. 

Set Submit message destination address 
= message extension field address. Keep 
received originating address i.e. do not 
set it to be application address. Send 
Submit message with user data originally 
received to Message handling 
Centre/SMSC. 



On receipt of Delivery message from 
Message Handling Centre/SMSC set that 
message originator can be located by 
party indicated in message extension 
parameter, in external location server 
database. 

Send Delivery Report message response 
(OK/not OK) to Message Handling 
Centre/SMSC. 



Allow location by 
the party indicated 
by the message 
destination address 



Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received message destination 
address. Set destination address 
= Application address and send 
Deliver message containing 
Submit message user data to 
Application using SMSC to 
Application protocol. 

When Deliver Report is 
received, send a Submit Report 
to message originator, 
containing Deliver Report User 
Data. 



Disallow location 
by the party 
indicated by the 
message destination 
address 



Deliver message 



Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received message destination 
address. Set destination address 
= Application address and send 
Deliver message containing 
Submit message user data to 
Application using SMSC to 
Application protocol. 

When Delivery Report is 
received, send a Submit Report 
to message originator, 
containing Delivery Report User 
Data. 



On receipt of Deliver message from 
Message Handling Centre/SMSC set that 
message originator cannot be located by 
party indicated in message extension 
parameter, in external location server 
database. 

Send Delivery Report message response 
(OK/not OK) to Message Handling 
Centre/SMSC. 



Set a message extension in the I If message originator (indicated by 
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and return 
receiver's location 




SMSC to Application protocol 1 
Deliver message to be = 
received message destination 
address. Set destination address 
= Application address and send 
Deliver message containing 
Submit message user data to 
Application using SMSC to 
Application protocol. 

When Delivery Report is 
received from the Application, 
send a Submit Report to 

message originator, containing 
Delivery Report User Data. 

Relay subsequently received 
Application-originated Submit 
message to the indicated 
destination address resulting 
from outgoing routing analysis, 
handling subsequently received 
Delivery Reports or Status 
Reports in the standard defined 
manner. 


message origination address) is allowed 1 
to position message receiver (indicated 
by message extension address) then 
retrieve message receiving party location 
from network 2 using message extension 
address, via external location server. 
Include retrieved location data in 
message user data in place of append 
originator's location Service Control 
Command. Send receiver's location as 
user data in an SMS Delivery Report 
message back to Message Handling 
Centre/SMSC. 

Set Submit message destination address 
= message extension field address. Keep 
received originating address i.e. do not 
set it to be application address. Send 
Submit message with user data originally 
received to Message hEmdling 
Centre/SMSC. 


1 Check pre-paid 
account balance for 
message receiving 
party 


1 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received message destination 
address. Set destination address 
= Application address and send 
Deliver message to Application 
using SMSC to Application 
protocol. 

Relay subsequently received 
Delivery Report User data to 
originator, in Submit Report 


Retrieve account balance and PIN that 1 
corresponds to the destination address 
stored in the Deliver message extension 
parameter. Validate PIN against the PIN 
sent as a Service Control Command 
parameter in Delivery message user data, 
and if valid send pre-paid balance back 
in a Delivery Report message to Message 
Handling Centre/SMSC 


1 Refill message 
receiving party's 
pre-paid account 


1 


1 Set a message extension in the 
SMSC to Application protocol 
Delivery message to be = 
received Submit message 
destination address. Set 
destination address = 
Application address and send 
Deliver message containing 
received Submit user data to 
Application using SMSC to 
AppHcation protocol. 

Relay subsequently received 
Delivery Report user data to 
message originator in an SMS- 
Submit Report. 


Retrieve account balance and PIN that 1 
corresponds to the destination address 
stored in the Delivery message extension 
parameter. Validate PIN or Voucher ID 
received in Delivery message against that 
retrieved from subscriber data, and if 
valid add payment amount corresponding 
to voucher ID or held in subscriber 
details to existing pre-paid balance and 
store new balance. 

Send resultant balance or error back in a 
application protocol Delivery Report 
message to Message Handling 
Centre/SMSC 


1 Request 
notification of 
message receiving 
party's attachment 

1 to a mobile 


5 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received Submit message 
destination address. Set 


Retrieve the presence information for the 1 
MS that corresponds to the destination 
address stored in the Deliver message 
extension parameter, from an external 
presence server. I 
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network 




destination address = 
Application address and send 
Deliver message containing 
Submit message user data to 
Application using SMSC to 
Application protocol. 

Relay subsequently received 
Delivery Report user data to 
message originator in an SMS- 
Submit Report. 

Relay subsequently received 
Application-originated Submit 
message to indicated destination 
address resulting from outgoing 
routine analvsis handlinff 
subsequently received Delivery 
Reports or Status Reports in the 
standard defined manner. 


Send an SMS Deliver Report containing 
the current presence state (busy, not 
reachable, idle) in user data, with 
message origination address set to 
message extension address and message 
destination address set to received 
origination address. The message is sent 
to the Message Handling Centre/SMSC. 

If the status is not reachable then request 
the presence server to notify the 
Application once the MS becomes 
reachable. When the Application receives 
the reachable notification from the 
external presence server, then the 
Aoolication formulates an SMS Submit 
message with the new state, with message 
origination address set to original 
message extension address and message 
destination address set to original 
received origination address. The Submit 
message is sent to the Message Handling 
Centre/SMSC. 


Allow attach 
indication to the 
party indicated by 
the message 
destination address 


6 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received message destination 
address. Set destination address 
= Application address and send 
Deliver message containing 
received Submit messasfe user 
data to Application using SMSC 
to Application protocol. 

Relay subsequently received 
Delivery Report user data to 
message originator in an SMS- 
Submit Report. 


On receipt of Deliver message by 
Message Handling Centre/SMSC set that 
message originator can have attach 
notifications sent to the party indicated in 
Deliver message extension parameter, in 
external location server database. 

Send Deliverv Reoort messase resnonse 
(OK/not OK) to Message Handling 
Centre/SMSC. 


Disallow attach 
notification to the 
party indicated by 
the message 
destination address 


6 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received message destination 
address. Set destination address 
= Application address and send 
Deliver message containing 

rftCftivfifi 5?iibnnit mftssap'e ii<5ftr 

data to Application using SMSC 
to Application protocol. 

Relay subsequently received 
Delivery Report user data to 
message originator in an SMS- 

Subniit Report. 


On receipt of Deliver message by 
Message Handling Centre/SMSC set that 
message originator cannot have attach 
notifications sent to the party indicated in 
Deliver message extension parameter, in 
external location server database. 

Send Deliverv ReDort messaffe reisnonse 
(OK/not OK) to Message Handling 
Centre/SMSC. 


Define user-defined 
item 


2 


Set a message extension in the 
SMSC to Application protocol 
DeUver message to be = 
received Submit message 
destination address. Set 


Remove the conmiand and any white 
space immediately preceding and 
following it from received Deliver 
message user data. Set the user defined 
text held against the subscriber indicated 
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destination address = 
Application address and send 
Deliver message containing 
received Submit message user 
data to Application using SMSC 
to Application protocol. 

Relay subsequently received 
Delivery Report user data to 
message originator in an SMS- 
Submit Report. 


by the message originating address to be 
= message user data, if the service is 
allowed for the subscriber. 

Send a Delivery Report message back to 
the Message Handling Centre/SMSC, 
with message origination address set to 
message extension address and message 
destination address set to received 
origination address. User data contains 
command execution status (OK/Not OK). 


Append user- 
defined item 


2 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received Submit message 
destination address. Set 
destination address = 
Application address and send 
Deliver message containing 
received Submit user data to 
Application using SMSC to 
Application protocol. 

Relay subsequently received 
Delivery Report user data to 
message originator in an SMS- 
Submit Report. 

Relay subsequently received 
Application-originated Submit 
message to destination address 
resulting from outgoing routing 
analysis, handling subsequently 
received Delivery Reports or 
Status Reports in the standard 
defined manner. 


Retrieve originating party user-defined 
data, using originating party address in 
received Deliver message as index into 

user-defined dataset. 

Include retrieved user-defibied data in 
message user data, in place of append 
originator's user defined item Service 
Control Command. 

Send a Delivery Report message back to 
the Message Handling Centre/SMSC, 
with message origination address set to 
message extension address and message 
destination address set to received 
origination address. User data contains 
command execution status (OK/Not OK). 

Set Submit message destination address 
= message extension field address. Keep 
received originating address i.e. do not 
set it to be Application address. Send 
Submit message containing modified user 
data to Message Handling Centre/SMSC. 


Send message copy 
to own e-mail 
address 


2 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received Submit message 
destination address. Set 
destination address = 
Application address and send 
Deliver message to Application 
using SMSC to Application 
protocol. 

Relay subsequently received 

Application-originated Submit 
message to indicated destination 
address resulting from outgoing 
routing analysis, handling 
subsequently received Delivery 
Reports or Status Reports in the 
standard defined manner. 


Retrieve originating party e-mail address, 
using originating party address in 
received Deliver message as index into 
user dataset. 

Using retrieved originating party e-mail 
address send a copy of the received e- 
mail an external e-mail server. Set the 
Message Handling Centre as e-mail 
sending address. Remove the send 
message copy to own e-mail address 
Service Control Conunand from the 
received message user data. 

Set Submit message destination address 
= message extension field address. Keep 
received originating address i.e. do not 
set it to be Application address. Send the 
Submit message with reformatted user 
data to Message Handling Centre/SMSC. 


Invite message 

receiving party to 
join my friend list 


6 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 


Retrieve originating party list of friend 
addressed, using originating party 
address in received Deliver message as 
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received Submit message 
destination address. Set 
destination address = 
Application address and send 
Deliver message to Application 
using SMSC to Application 
protocol. 

Relay subsequently received 
Application-originated Submit 
messages to indicated 
destination address resulting 
from outgoing routing analysis. 

Relay Deliver Report to 
indicated message Relay Layer 
destination, mapping Deliver 
Report into a Submit Report. 


index into user dataset. 
Remove the Invite message receiving 
party to join my friend list' Service 
Control Command from the received 
Deliver message user data. 

Set Submit message destination address 
= message extension field address. Keep 
received originating address i.e. do not 
set it to be Application address. Send the 
message with reformatted user data to 
Message Handling Centre/SMSC. 

Construct an invitation Submit message 
with message origination address = 
Application address and message 
destination address = received message 
extension address and send it to the 
Message Handling Centre/SMSC. When 
Submit report is received, if it indicates 
OK then add party to friend list. 

Construct a Deliver Report message 
towards the originating party indicating 
whether the party was added as a friend 
or not. Send Deliver Report to the 
Message Handling Centre/SMSC, 


Locate message 
receiving party 


6 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received Submit message 
destination address. Set 
destination address = 
Application address and send 
Deliver message containing 
received Submit message user 
data to Application using SMSC 
to Application protocol. 

Relay subsequently received 
Application-originated Delivery 
Report message as a Submit 
Report message to indicated 

destination address. 


If message originator (indicated by 
Dehver message origination address) is 
allowed to position message receiver 
(indicated by Deliver message extension 
address) then retrieve receiving party's 
location from network 2 using message 
extension address, via external location 
server. 

Include retrieved location data in Deliver 
Report message user data in place of 
append originator's location Service 
Control Command. Send destination 
party location in user data in an SMS 
Delivery Report message back to 
Message Handling Centre/SMSC. 


Send a real-time 
message to the 
receiving party, and 
request notification 
of network 
attachment by the 
receiving party 
when message 
delivery fails 


4 


Set a message extension in the 
SMSC to Application protocol 
Deliver message to be = 
received Submit message 
destination address. Set 
destination address = 
Application address and send 
Deliver message containing 
received Submit message user 
data to Application using SMSC 
to Application protocol. 

Relay subsequently received 
Application-originated Submit 
message to destination address 


Remove the Service Control Command 
from the received Deliver message user 
data, and set the Submit message 
destination address = message extension 
address. Keep received originating 
address i.e. do not set it to be Application 
address. Send Submit message containing 
modified user data to Message Handling 
Centre/SMSC. 

Send Deliver Report to Message 
Handling Centre/SMSC. 

If message delivery fails and the status is 
not reachable then the Application 
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resulting from outgoing routing 
analysis, handling subsequently 
received Delivery Reports or 
Status Reports in the standard 
defined manner. 



requests the presence server to notify it 
once the MS becomes reachable. When 
the Application receives the reachable 
notification from the external presence 
server, then the Application formulates 
an SMS Submit message with the new 
state, with message origination address 
set to original message extension address 
and message destination address set to 
original received origination address. 
User data indicates that the user is 
reachable. The message is sent to the 
Message Handling Centre/SMSC. 



FIG. 4 
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Start 




I 



MO Forward SM 
Message Containing 
SMS-Submit 



T 



Application 
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\^MS-Submit 



Messages received/sent to left 
are from GSM core network. 
Messages received/sent to right are 
From/to applications 

Zl 




Check messaging 
allowed for 
originator 




Not Allowed 



Allowed 



Invoke Message 
Handling Centre 



Finisii 



FIG. 5a 



Invoke Message 
Handling Centre 



Perform outgoing 
Route analysis 



Route type is GSM 





Send MO Forward SM 
Message Containing 

SMS-Deliver to MS 



Messages received/sent to left 
are from/to GSM core network 
Messages received/sent to right 
are from/to Sen/Ice Control 
Comm^d Applications 



Route type is application 



Send message 
containing SMS-Dellver^ 
to application 



Handle subsequent 
nnessages 
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Handle subsequent 
messages 



Messages received/sent to left 
are from/to GSM core network 
Messages received/sent to right 
are from/to Service Control 
Command Applications 



SMS / 
deliver Reporrv 



Handling of 
SMS-Deliver 
Report received 
from applications 




Receipt of SMS\ 
Deliver Report/ 



Handling of 
SMS-Delivery 
Report received 
from GSM 
network 



Exit 

■ 

Note: Error handling in the event of 
the receiver not being reachable 
is not shown here, for simplicity 



FIG. 5c 



Response 
modification 
Type not 
stored 



Handling of SMS-Delivery 
Report received from 
application 




Response 
Modification 
Type stored 



Make new/modify stored 
SMS Submit Report using 
received Deliver Report 
User data 



Messages received/sent to left 
are from/to GSM core network 
Messages received/sent to right 
are from/to Sen/ioe Control 
Commcind Applications 



Message originator 
is MS 





Send SMS Submit Report 
to message originator 



Message originator 
is application 



Send SMS-Submit 
Report to application 




Exit 



FIG. 5d 
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Response 
modification 
Type not 
stored 



Message originator 
is MS 




Handling of SMS-Delivery 
Report received from GSM 
network 




Messages received/sent to left 
are from/to GSM core netwoiic 
Messages received/sent to right 
are from/to Serwce Control 
Command Applications 



Response 
Modification 
Type stored 



Mal<e new/modify stored 
SMS Submit Report using 
received Deliver Report 
User data 




Send SMS Submit Report 
to message originator 



Message originator 
\s application 



Send SMS-Submit 
Report to application ^ 



Exit 



FIG. 5e 



Perform outgoing 
Route analysis 



Parse MO SMS 
Message for Service 
Control Command(s) 
I 



Read network dependant 
routing infomnation and 
obtain parameters required 

for outgoing rniite analysifi 



Messages received/sent to left 

are from/to SMSC 
Messages received/sent to riglit 
are from/to Service Control 
Command Applications 



Dependant upon the parsing 
rules, one or more service 
Control commands can be 
used to together as an input 
to outgoing route analysis 
to determine destination 
routing and routing type 



Select outgoing route using 
End-user and network 
Input parameters 




< 






Store response modification 
type if obtained and Incoming 
message requests report 




J , 




Exit 



Output comprises a route 
type (used to select the 
means of message 
transfer), user data 
response modification type 
(insert location in response 
message, etc) and a routing 
destination 
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